home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0524.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  3.9 KB  |  79 lines
  1.  
  2. > Pity Scotland didn't do so well. :I
  3.  
  4. > Yep, and today is all black when france losed in penalties and 
  5. > england too:-(((((((((
  6.  
  7. :(
  8.  
  9.  
  10. > A little bit faster is always beeter than a little bit slower:-)
  11. > Anyway a straightforward question: On an previous discussion you said 
  12. > that the monsters etc. was to be handled as transparent walls? so 
  13. > when the monsters are there they will surely slow down the framerate, 
  14. > because it's the same effect as a complex room??
  15.  
  16. It doesn't really work like that. The transparent walls take lots of time
  17. because they are floor-to-ceiling, wall-to-wall, which gives them a very
  18. large surface area. It's the surface area that 'hurts'. The other factor
  19. is that the engine doesn't stop drawing when it hits a transparent wall.
  20. It has to keep going until it finds a solid one - so a transparent wall
  21. automatically means lots of additional drawing beyond the wall itself,
  22. as if you can see directly into yet more rooms. This just adds to the
  23. problem.
  24.  
  25. Sprites are much smaller, they don't increase the complexity of the room
  26. and they are not perspected. This all helps a great deal. BM's wall calculation
  27. is optimised for non-perspected (face-on) walls so sprites will draw a little
  28. faster anyway.
  29.  
  30. Even if there is a speed problem, there is one final (very difficult)
  31. upgrade which can be made to speed up sprites & transparencies - but
  32. there is a cost. The compexity of the sprite's mask will determine how
  33. fast it will draw. A squarish, or roundish sprite with only a few 'holes'
  34. will be quick, while a 2x2 pixel checkerboard of pixels and holes will
  35. be the worst case possible. You can probably work out the rest from there.
  36.  
  37. I'd like to avoid having to do this if possible, because it's quite involved
  38. and I have less and less free time these days. :)
  39.  
  40. > Great! You said before that you thought that Doom cheated alot in the 
  41. > perspective calculations and that if you could found out the cheat 
  42. > you could speed up things even more, have you found that cheat??
  43.  
  44. In Doom, every pixel-wide 'column' in each wall, and every pixel-high 'row'
  45. in each floor must be inverse-perspected to find out where in the texture
  46. to start fetching pixels from. This is extremely difficult, and very intensive.
  47.  
  48. I am currently using a method I devised myself, but I have no idea how much
  49. it is like the actual Doom method - all I know is that every other method I
  50. used failed due to lack of precision. The most obvious methods even failed
  51. using a 68882 with 80-bit accuracy! I eventually managed to succeed using
  52. a rather odd approach & with 24-bit & 48-bit fixed point maths (which is
  53. MUUUUCH less accurate than a 68882!).
  54.  
  55. I now have an idea about Doom's own method, and it is a real cheat. It explains
  56. how they manage to do it so quickly. They use a simple fudge to produce a
  57. 'curve' which closely matches the real 1/z perspective curve. It's not identical
  58. by any means, but it's close enough. The system itself is simply to use a quadrant
  59. of a sinewave - basically a lookup table (which is not very intensive at all) but
  60. unfortunately, if you fudge this bit using tables, then you must also fudge the
  61. other 'real' perspective in the 3D polygon engine - otherwise your walls won't
  62. match up with the textures supposed to be attatched to them. Do you see what I mean?
  63. If you hack 10% then you have to hack 100%. I don't want to do that much damage to
  64. Bad Mood, and the DSP does a good job already. There would probably be little
  65. or no saving at the end of the day, since the 68030 would need to replace the
  66. DSP in this case due to memory requirements for the huge lookup tables.
  67.  
  68. If you want to see this sinewave trick in action, then look at the sky texture
  69. in quake as it reaches the horizon - you will see that it starts to 'stretch'
  70. as it approaches the middle - there is no real horizon. This is te point where
  71. the sinewave table matches the perspective curve LEAST. It just happens to
  72. look nice in quake's sky. :)
  73.  
  74. Anyway, in a nutshell, it's not really worth trying anymore.
  75.  
  76. Doug.
  77.    
  78.  
  79.